ETO Development Tools 4/ETO Development Tools 4.iso/Essentials/MacApp Documentation/MacApp.TECH$ Archives/1990/Sep 90/MacApp.Tech$ 9⁄14⁄90/1950-Genericity etc.-Sep90

Text File | 1991-03-06 | 5.6 KB | 107 lines | [TEXT/GEOL]

Item    8545306                         8-Sept-90        12:34PDT

From:   MADA.EUROPE                     MacApp Dev Assoc Eur,E Carrasco,IDV

To:     MACAPP.TECH$                    MacApp Technical

Sub:    Genericity etc.

Barry, Derek & friends;

I have followed the thread on Multiple Inheritance with great interest. I would
rather read this than the Sunday funnies. Really. I download MacApp.Tech$ and
wow, what a way to spend Saturday morning!

From what has been able to penetrate the foggy recesses of my mind, it seems to
me that references to uses for MI seem to fall into three broad categories:
1) We want to subclass from two or more existing libraries the source code of
which we do not have or do not want to tamper with.
2) We knowingly and willfully create a class hierarchy that is designed to make
efficient use of MI.
3) We have a design problem and so we use MI as a shortcut.

There is not easy way to get around the first need. If you really need both
building blocks, then you need MI, or you will have to write wrapper functions.
Both are legitimate solutions. Which one is ideal would depend on the real
world model we are working with. If you think about it, very few man made
objects are actually the result of multiple inheritance. A seaplane is not an
airplane *and* a boat. It is never used instead of a boat nor is it sold to
someone who needs a boat. It is an airplane that *has* a hull and/or pontoons.
The use of a field to contain an object that has behaviour we wish to add to
our object is *not* an artificial way to avoid MI. It is a valid representation
of reality. Almost everything we own is nothing more than an amalgamation of
other things. Industry uses the word "subassembly" to describe the component
parts of such things. If our objects are very small and only do one thing, and
we combine them into subassemblies, it is true that we may be forced to write
wrapper functions to export their behavior. But it is also true that once a
subassembly is well defined, it may be grafted into another subassembly without
going into contortions and fits of anguish because of a class hierarchy that
was ill conceived.
Besides, I am a little skeptical about inheriting from two different libraries
written independantly. You would inevitably inherit baggage you didn't need.

As for the second type of need, where programmers for reasons obscure willfully
and knowingly create MI hierachies, I will abstain from all comment. The
question has been covered by those more apt to shed light on it.

The perversity of human nature being what it is, I was not surprised to
discover that nearly all of the cases where I felt I could use MI have finally
proven to belong to the third category, that is the need was perceived but not
real.

Which brings me to the focal point of my diatribe.

I started writing this link during the week but decided to wait until I
downloaded MacApp.Tech$ before posting it. What joy and disappointment to find
my suggestions posted already! So I'll recapitulate and put in my two cents
worth for the OP++ compiler writers :

1)Genericity: I didn't know until now that it was called genericity. While on
the surface it has absolutely nothing to do with MI, I agree with Barry Wilson
that many temptations to use MI would disappear if I could "patch" an existing
class declaration by inserting my class into an existing hierarchy. Derek, you
said "The ability to slip your own class into someone else's hierarchy may
solve some problems, but could also be very dangerous." I would like to know
why it would be dangerous. It seems like a perfectly benign thing to me. (am I
an innocent and simple minded programmer?) It is definately at the top of my
wish list for OP++. Can you imagine the number of TView improvements that would
crop up overnight if this were possible?
1b)What are parameterized types?

2) Private Data: Smalltalk data is private. Apple's unofficial C++ guidelines
insist that all data members be declared private. Good OP technique dictates
that data never ever ever be accessed without accessors. Why not make all
fields private and be done with it? I see no use for public data. Even most
globals can safely be dispensed with.
As for the tons of code that will no longer work, the programmers have been
warned for long enough. At worse they'll have to spend a weekend writing SetFoo
and GetFoo methods. Someone may even write a tool that would do it
automatically.
As for the argument that it is useless to write alot of methods that do nothing
but set and get fields, I agree. They should do something useful like range
checking and error signaling.

3) Private methods. I don't see that it would be necessary to redeclare a class
in the IMPLEMENTATION. Besides, it would be a pain. You could just declare the
method like any old procedure, as long as the class name used in the method
declaration was valid. Of course that would not solve the protected problem
which is important if only to acheive a degree of C++ compatability.

4) Functional syntax: I am leery of it. I think INHERITED is better. When I
find myself wanting to call on granddad, I go back over my hierarchy to see
what is wrong. (of course if the hierarchy is not my own, there is nothing I
can do -- unless (1) is implemented)

In conclusion, I do not believe that OP must get into a feature war with C++ in
order to survive. Its two main features, simplicity and elegance are out of
reach for C++. If the features described in the preceding links are
implemented, then it will retain a large number of followers even if Apple
Computer Inc. is not among them.

Mac 'Appily yours,


Peter Adamson
MADA.EUROPE